In a modern computing system, access control lists (ACLs) are commonly used to enforce access rights to individual data objects in the system, such as a program, a process, or a file. See, generally, Wikipedia. The ACL is a means of determining the appropriate access rights to a given object given certain properties of a user (or process executed by the user) that is requesting access to the object. Id. The principal property that determines a user's access rights is the user's identity. Id.
An ACL is a data structure, usually a table, containing entries that specify an individual user's rights to specific system objects. Id. These entries are known as access control entries (ACEs) in the context of some popular operating system environments, such as MICROSOFT WINDOWS and OPENVMS. Id. Although each entry may associate a particular right with a single user, each entry more commonly associates a particular right with a group of users. Typically, the groups are defined in a separate data structure and an ACL merely includes a reference to the external group definition, but groups also may be defined within an ACL itself. Specific access rights (also known as “privileges ” or “permissions”) available in a specific system vary, but typically include rights to read from, write to, or execute an object. Each accessible object contains an identifier that references its ACL.
A “data object,” though, is an abstract entity, and one data object may be a container for other objects. Thus, in theory, a single ACL that is defined for a container object can provide effective access control over a large number of individual objects within the container. But a computing system commonly needs to control access to large numbers of containers and to provide varying degrees of access to large numbers of objects within each container. The complexity of administering ACLs increases proportionally as the number and individual data objects that must be controlled increases. These complexities, and thus the inherent disadvantages of ACLs, are best demonstrated with a simple example. In this simple example, an enterprise content management (ECM) system organizes documents in a hierarchical tree structure that reflects the enterprise's organizational structure, such as the organization in FIG. 1, and ACLs are used to control access to the documents according to two simple business rules. The first rule is that users with update access to a node in the tree must have update access to all descendants of that node. The second rule is that users with update access to a node in the tree must have read access to all ancestors of that node.
The hierarchical tree structure of FIG. 1 represents an enterprise with a three-tier management structure, where each office or department is a node in the tree. According to the business rules described above, each officer or manager (and their respective delegates) are authorized to update their own documents and those documents belonging to any office or department that reports to them (i.e. is below them in the tree). Thus, Sam (as the CEO) and Sally (as his delegate) have the authority to update documents owned by the CEO, as well as documents for the entire enterprise. Thus, the CEO and the CEO Delegate are authorized to update not only documents associated with the CEO, but documents associated with the CFO and the CIO, as well as the departments that report to the CFO and CIO. Similarly, Bill (as the CIO) and Bonnie (as the CIO's delegate) have the authority to update the CIO documents, as well as the Intranet and Internet documents. Ann, the CFO, and Ann's delegate are authorized to update the CFO's documents, Accounting documents, and Finance documents. Neither the CIO nor the CFO, nor either of their delegates, however, has the authority to update the CEO's documents, but all are authorized to read those documents. Finally, on the lowest tier, Charlie, Donna, Edward, Frank, and their respective delegates have the authority to update the documents in their respective departments and the authority to read the CEO documents. In addition, Charlie and Donna have the authority to read the CFO documents and Edward and Frank have the authority to read the CIO documents. But neither Charlie, Donna, Edward, Frank, nor their delegates are necessarily authorized to read or update documents that belong to other departments on the same tier.
ACLs are flexible, and there are several ways to implement these business rules with ACLs. In one such implementation, an ACL uses a “reader” group and an “updater” group defined for each node in the tree, and each group identifies each individual user explicitly. Consequently, each group generally includes users from all over the hierarchy, which can be very inefficient and prone to errors if managed manually. Each ACL also defines only two rules—one rule that grants read access to the reader group and a second rule that grants update access to the updater group. This type of ACL implementation is illustrated in FIGS. 2 and 3. Note that the ACLs in this implementation are fairly straight-forward, and the access rules are essentially implemented in the group definitions. In practice, each document in a given node would include a reference to the appropriate access rule in FIG. 3, and each access rule might be identified by some arbitrary key value. Thus, any document in the CEO node would include a reference to the CEO access rules, which are defined in the first two rows of FIG. 3. For the sake of simplicity in this discussion, though, the access rules identified in FIG. 3 (and in the figures that follow) are given names that reflect the type of documents that they control.
In an alternate implementation, an ACL defines a single group corresponding to each node, but defines multiple rules that control each group's access to any given node. This implementation, illustrated in FIGS. 4 and 5, simplifies the group definitions at the expense of increasing the complexity of the access rules for each node.
Some ACL implementations also support the concept of “nested” groups. As illustrated above, standard ACL groups only identify individual users. Nested groups, though, can identify individual users and other groups. Thus, the example ACLs described above could be modified with nested groups, as illustrated in FIGS. 6 and 7.
Thus, these examples demonstrate the capacity of ACLs to implement a basic set of business rules in a simple organizational structure. The shortcomings of ACLs, though, become readily apparent when the organizational structure is modified slightly. Suppose, for example, that the enterprise adds an Audit Department that reports to the CFO. Moreover, anyone in the Audit Department should have read access to any document in the hierarchy, as well as annotate access to any document in the hierarchy. Here, “annotate access” includes authority to electronically highlight portions of the document, add electronic notes, and the like. In the implementation that uses nested groups (see FIGS. 6 and 7), this means that three new groups must be defined and every ACL in the hierarchy must be modified to give the Audit Department the authority to read and annotate everyone's documents. These changes are illustrated in italic typeface in FIGS. 8 and 9.
To implement the two original business rules for the Audit Department, note that the CFOReaders group also must be modified and new access rules created for the Audit Department. And because the existing groups are built specifically to accommodate those who need Read access and those who need Update access, these groups cannot be leveraged to add the Audit Department's annotation rights. Accordingly, a new access rule must be added to each node, as illustrated in FIG. 9.
As the above examples illustrate, ACLs provide a flexible mechanism for controlling access to a relatively small, static enterprise. Nested groups address some problems associated with larger or more dynamic enterprises, but as the above example also illustrates, ACLs—even ACLs that support nested groups—can require an enormous amount of administrative overhead even for relatively minor changes to a small enterprise. Thus, there remains a general need in the art for access control systems that overcomes the limitations of ACLs that impede effective administration in larger, more dynamic enterprises.